Subject: minor flow control issues

From: [email-masked]
Date: Mon, 6 Jun 94 08:56:20 EDT

Everyone,
In addition to the sender feedback work item currently under discussion,
there are a number of smaller flow control issues that need resolution
before we seek AD status on our work product.  I have made a list below
with my suggested resolution.

Please agree or disagree with the resolutions I suggest.
Thanks,
Peter
-----------------------------------------------------------------------
1) Clarifications to the general proposal
   - Add that the response to PREQ+RWI must include IWI
   - Add that the pacing flags byte is in the long header also

2) Is CONNECTED the only state in which pre-standard nodes support
   x_BUSY?

   The old 6611 FSMs showed xBUSY being supported in lots of states.
   Steve Klein's newest set removes these lines, because of various
   agreements reached in Anaheim.  So the only language about xBUSY
   in the AIW standard will be in the flow control part of a "back
   level compatibility" section.  I have not polled vendors of pre-
   standard implementations, but I suggest that this language require
   xBUSY support only in CONNECTED state.

3) Resolve whether DATAFRAMEs are paced in CONNECTED / CIR_ESTABLISHED
   states.

   As near as I can tell, DATAFRAME in these states is an anomaly.
   I believe we should pace only DGRMFRAME and INFOFRAME since they
   are explicitly tied to an existing circuit, and not count DATAFRAMEs.

4) Resolve exactly which circuit states pacing operates in, and how
   state transitions are handled.  See my exchange with Bernie Brady
   ending on 3/14/94 about CIRCUIT_ESTABLISHED state.

   After giving this some thought, I feel the scheme would be most
   robust if it were tied only to frame types and not to circuit
   states.  It is then absolutely clear which frames are counted
   even if the two DLSw nodes are slightly out of sync with regard
   to circuit states.  I would propose that DGRMFRAME and INFOFRAME
   be subject to counting regardless of circuit state.  The only
   place in the FSMs where this rule seems strange is DGRMFRAME
   coming from CIRCUIT_PENDING state, but I believe this is an error
   and should be DATAFRAME since the sending node does not have a
   circuit id from the origin node at the time it sends the frame.

5) Resolve whether a node is REQUIRED to send HALT_DL_NOACK if
   a pacing window is exceeded (or other pacing protocol error if
   there are any), or if this is a product choice.

   I suggest this be a product choice, but I do not feel strongly
   about this.  If anyone feels we should require a HALT..., please
   provide a list of the protocol errors also.  I don't think it's
   fair to require an action but not spell out the checks required.

6) Decide when to set PRSP on reset IPMs:  never, when PRSP is
   owed, or always.

   I favor "when PRSP is owed" since that tells whether the pacing
   receiver saw PREQ before it decided to send a reset.  I'm not
   sure this information is useful, but why not provide it?  The
   current proposal has "never".

7) Discuss or boot "management considerations"

   I think this discussion should be carried out on the MIB mailing
   list.  If people agree, we can post the small section from
   pacing-02.txt as the starting point for the flow control section.
   I think we should consider adding the sender's state variables
   to the current circuit-level objects.

Peter

---

From: "Shannon Nix" <[email-masked]>
Date: Wed, 15 Jun 94 09:25:10

Hi Peter,

Sorry for the delay in responding.

My comments below

------------------------------------------------------------------ 
1) Clarifications to the general proposal
   - Add that the response to PREQ+RWI must include IWI
   - Add that the pacing flags byte is in the long header also
   
   SN - Agree (assuming still relevant when discussion converges)

          
          SN - Which prestandard implementations actually send
          xBUSY?  In what states do they send them? Which prestandard
          implementations actual honor xBUSY?  In what states do they honor 
          them? Do we want to support any or all of the above?

          
          SN - We should count all frames (non-SSP-protocol) that can
          be assigned to a circuit.  Those that can't be assigned to
          a circuit can't be counted under the current scheme (at least
          not in a tidy fashion!) 

   
     SN - I think it should be tied to certain frame types as well.  
     All frames which have meaning outside SSP, which can be         
     assigned to a circuit.
     I also believe that the receiver should explicitly "grant" the  
     first window.  This should handle the state-stuff shouldn't it? 
     ..ie. when I'm ready to receive the frames we're going to       
     count, then I'll let you know.

          
          SN - Product Choice

          
          Why not?

          
          Should take place in the MIB group.
Peter

  Rgds, Shannon